Content conversion logic for incoming MIME (multi-purpose Internet mail extensions) messages involves shredding the message and saving select body parts in various MAPI (messaging application programming interface) properties. The “best” body of the message is promoted to the appropriate property and attachments are saved in the attachment table. Body parts that are not supported by MAPI clients are discarded, along with alternative representations of the “best” body in a multipart/alternative block. This process works well for certain MAPI clients for which the current content conversion logic is optimized. However, this creates significant issues for IMAP (Internet message access protocol) and POP (post office protocol) clients which need email in the store to be converted back to MIME before these clients can consume the message.
Converting a message from MIME to MAPI and back to MIME creates two problems for these standards-based clients, that impact performance and message fidelity. With respect to performance, conversion from MAPI to MIME is an expensive process and needs to be carried out each time a standards based client requests information on an email message. Even if only top level headers are requested, the full MAPI-to-MIME conversion takes place. This severely impedes IMAP client performance. With respect to message fidelity, due to the lossy nature of the current content conversion logic, the MIME message the client sees is not the same as the original MIME message that was received by the server. This can result in unpredictable behavior for certain IMAP clients which expect any saved content to be returned exactly as it was stored.